Throughout this specification the use of the word “inventor” in singular form may be taken as reference to one (singular) or all (plural) inventors of the present invention.
The inventor has identified and considered the following technologies.
In general, an embedded system is a system within a larger system. Embedded systems may be implemented on a single integrated circuit or as scaled-down software code. Alternatively, embedded systems may comprise analog components. An embedded system typically has a specialized function with programs stored on ROM. Examples of embedded systems are chips that monitor automobile functions, comprising engine controls, antilock brakes, air bags, active suspension systems; industrial process devices, for example comprising robotic systems in production engineering applications or medical applications; environmental systems, comprising pollution monitoring devices etc; entertainment systems and; property protection systems, comprising for example security devices, fire prevention or smoke detection devices and combinations thereof. Ordinarily, everything needed for those functions is custom designed into specific chips and, there may be no external operating system required. Many embedded systems are produced in the range of tens of thousands to millions of units. Reducing costs in all aspects of design to actual production, installation and maintenance is therefore a major concern. There may be many different CPU architectures used in embedded designs. This contrasts with the desktop computer market, which is limited to only a small number of competing architectures, such as, Intel™'s x86, and the Apple™/Motorola™/IBM™ PowerPC™. A common configuration for embedded systems is the “system on a chip”, an application-specific integrated circuit. It is also notable that user interfaces for embedded systems vary to a large extent. The resultant complexity of most embedded systems requires that generally they are developed in teams by several developers at the same time using different computer platforms. Furthermore, high performance micro-controllers which are now available may provide developers with highly complex software solutions for embedded system design. Managing the complexity of software components and their inter-workings has therefore also become a major concern.
Rational™ Robot is a PC application designed for the design and execution of tests on PC applications. Therefore, in an attempt to provide a test environment for embedded systems by use of Rational™ Robot, a Data Driven Engine (DDE) is required to deal with the complexity of generating tests within a PC environment and translating those tests into a syntax that may be interpreted by additional interface hardware.
Visio™ is an application where a message sequence chart (msc) representing a test case or sequence may be constructed and then via interfacing Visual Basic code representing the Visio™ msc to Labview™, a graphical programming language tool. The Labview™ functions may then interpret this code and execute the test on a DUT. It is to be noted that Labview™ being the programming environment, still needs to interface physically and logically to the DUT via specific I/O hardware. There is also an issue of having to reconstruct from scratch the entire msc every time there is a change to the underlying test sequence requirements.
A product from Lucent™ known as UBET employs an enhancement of msc's, namely, HMSC (Hierarchical Message Sequence Charts). The limitations of the Visual Basic scripts are removed in this implementation, however, the inventor has identified that there still remains the issue of reconstructing from scratch the MSC's and HMSC's with every iteration in requirements or change in requirements of a test sequence for embedded systems.
Generally, “black box” test environments do not exist for embedded systems, in particular, systems that are not built on or do not employ industry standard communications protocols. In a niche market, such as is filled by the fire and smoke alarm products developed by Vision Fire & Security Pty Ltd and marketed under trade marks such as VESDA®, the communications protocols are developed in house and are not serviced by major industry developers of automation systems, for example, such as TTCN2 and TTCN3. Thus, it is considered that there is little or no means in existence to leverage off the activity of cooperating industries and user groups.
In general, test automation environments such as Rational™ Robot are contemporaneous with other automation environments such as WinRunner™ and other PC and GUI focused applications. The inventor has identified that these environments are designed in a manner, which may not communicate with, stimulate, or control embedded systems. The inventor has further identified that attempts to retrospectively adapt these environments through the addition of interpreters or hardware interfaces necessitates very large efforts in terms of scripting and definition of key words and phrases. Moreover, the inventor has identified that test designing within these environments requires repetitive manual labour. Overall, the inventor has identified use of these environments to be time consuming, difficult to maintain and labour intensive in generation and updating and, unable to adequately deal with any changes in requirements and project scope.
The inventor has further identified that, under such environments, bridging the divide from formally defined tests to physically interfacing to a product that is controlled via embedded software and automatically executing tests introduces difficulty given that very few user accessible interfaces are generally available for stimulus and reading of responses from embedded DUTs.
Any discussion of documents, devices, acts or knowledge in this specification is included to explain the context of the invention. It should not be taken as an admission that any of that material forms a part of the prior art base or the common general knowledge in the relevant art in Australia or elsewhere on or before the priority date of the invention disclosed herein, being the subject of the appended claims.
An object of the present invention is to provide functional tests for embedded systems at a system-wide or black box level in a manner that is responsive to changing test requirements.
A further object of the present invention is to alleviate at least one disadvantage associated with the prior art, or at least provide a useful alternative.